home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄24⁄90 / 1812-Re[2] >Multiple Inhe-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.1 KB  |  70 lines  |  [TEXT/GEOL]
  1. Item    2793943                         24-Aug-90        16:21PDT
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     POWERUP.DEV                     Power Up Software,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: RE>>Multiple Inheritance
  10.  
  11. Meyer has a good discussion of reuse by inheritance or by instance in his book
  12. (section 14.5 "Would you rather buy or inherit?").  Also, in section 10.2.2 he
  13. says that inheritance represents the "is-a" relationship.
  14.  
  15. He also uses the example where the class FIXED_STACK inherits from STACK (an
  16. abstract class) and ARRAY, so as to use ARRAY's implementation (section
  17. 10.4.1).  In this case, note that the features of ARRAY are not exported.  (At
  18. least that's what it looks like to me; I'm not an Eiffel expert.)  This means
  19. that FIXED_STACK is not a subtype of ARRAY.
  20.  
  21. As far as the design is concerned, there is no difference between inheriting
  22. from ARRAY (and not exporting its features) and using an instance of ARRAY in
  23. the implementation.  The interface to the FIXED_STACK class is the same in
  24. either case.
  25.  
  26. The title of the section ("The marriage of convenience") is telling.  It looks
  27. to me that he did this either because it is more efficient that way or easier
  28. to program (fewer characters to type), not because it is a better design.
  29.  
  30. In the past, I gave a reason why Meyer's approach in this particular case can
  31. be undesirable.  If FIXED_STACK inherits from ARRAY to provide its
  32. implementation, it is explicitly tied to that implementation.  If it uses an
  33. instance of ARRAY internally, it is free to use different implementations in
  34. different instances, or even dynamically change its implementation.
  35.  
  36. Meyer mentions this in section 14.5, when he says that inheriting is a more
  37. committing decision.
  38.  
  39.  
  40. Regarding Geoff's example:
  41.  
  42. One way to handle this might be to make TTrackingGridView a subclass of
  43. TTrackingView, and have it contain an instance of TGridView.  TTrackingGridView
  44. would also have to implement the GridView methods and delegate to the embedded
  45. GridView instance.
  46.  
  47. The reason this might work is that (as far as Geoff has explained it) nothing
  48. in the scenario depends on TTrackingGridView being a subtype of TGridView, but
  49. TDesktopDragger does depend on it being a subtype of TTrackingView.
  50.  
  51. It wouldn't be hard to add to the example something that would require
  52. TTrackingGridView to be a subtype of TGridView, and then this implementation
  53. would no longer work.  You would definitely need multiple inheritance.
  54.  
  55. Note that multiple inheritance isn't a panacea in this case either.  You would
  56. end up having to make a TTrackingxxxView class for each existing TxxxView
  57. class.  The problem is that the tracking features really does belong in the
  58. TView class.
  59.  
  60. As far as the future of MacApp goes, I don't know.  I don't see it moving into
  61. C++, in the immediate future.  I think there are still a lot of developers who
  62. prefer to use Pascal, so that MacApp has to support both languages.  Until
  63. there is an implementation of Pascal++, I think MacApp will be constrained to
  64. the common subset of langauge features.
  65.  
  66. Larry
  67.  
  68.  
  69.  
  70.